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(54) System and method for determining and manipulating configuration information of servers 
in a distributed object environment 



(57) A computer system in a distributed object pro- 
gramming environment includes a number of host com- 
puters providing services to clients on a network 
through internally stored servers. Various types of con- 
figuration information for each server are available to cli- 
ents through persistent server administrators, which are 
objects containing such information about individual 
servers. A server administrator can store such informa- 



tion as startup execution definitions, saved program def- 
inition, object interfaces and implementations, reaping, 
tracing, and logging configuration data. Being persistent 
and external to the server, the server administrator can 
manipulate arxl determine its information about a server 
in response to client requests without starting up the 
server, thereby facilitating system administration. 
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Description - 
COPYRIGHT NOTICE 

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The 
. copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the 
Patent and Trademark Office patent files or records, but otherwise resen/es all copyright rights whatsoever. 

RELATED APPLICATION 

w 

This application is related to the European patent application entitled. SYSTEM AND P^/iETHOD TO CONTROL 
AND ADMINISTER DISTRIBUTED OBJECT SERVERS USING FIRST CLASS DISTRIBUTED OBJECTS, our refer- 
ence FB 5842, filed simultaneously with this application. 

15 BACKGROUND 

Field of Invention 

This invention relates to the field of object oriented application and operating systems development, and more par- 
20 ticularly. to methods and systems for performing administrative operations on object oriented applications operating in 
a distributed object programming environment. 

Background of Invention 

25 Client-server computing is the predominant model for the management of computing resources, typically on a net- 
work of distributed computers. Servers are computers and application programs executing thereon that provide various 
functional operations and data, upon request. Clients are computers and applications that request such services. While 
clients and servers may be distributed in various computers on a networK they may also reside in a single computer, 
with individual applications providing client or server functions, or both. 

30 In a client-server system based on a object oriented development environment, a client is code that invokes or 
manipulates an object, and the object that is invoked is the server. A server provides a number of interfaces to clients 
for invoking various objects within the server that provide functionality requested by a client. Each of the objects may 
have multiple implementations, or object code that executes the functionality of the code when an instance of the object 
is created by the server. Thus, a particular interface, when used by a client to invoke an object, will result in the execu- 

35 tion of a particular implementation for the object that is invoked. When the server or one of its objects is invoked, the 
server will operate in accordance with certain configuration information, such as the location of its data directory, the 
executable pathname, and the like. In a client-server system, it is desirable to be able to determine and manipulate the 
configuration information for a server available on the network without consuming system resources by invoking the 
server. 

40 Information about a server can be classified into two categories. Dynamic information adses out of a particular 
process that is executing a server, such as its process identifier, how many objects are active within the server, and the 
like. This information is dynamic because it depends on a current executing process which is transient. Static informa- 
tion is information that does not devolve from a particular execution or process. This includes external information such 
as the identify of the host computer of where the server is installed, its pathname, its execution definition, and internal 

45 information, such as the identity and description of the object interfaces and inplementations the server provides, and 
the setup of various application programming interfaces used by the server, such as the identity and configuration of 
tracing facilities available in the server, log file configurations, and reaping functions. 

Conventionally, systems administrators have various software tools for determining the configuration and related 
information about servers on various computers on a network. However, these administrative tools require that the 

50 server be executing as a process for any information to be obtained, and thus require an inactive server to be started 
up. merely to obtain or manipulate configuration and similar information. Such startup procedures limit the flexibility of 
the administrative tools, and require unnecessary consunption of computer resources. This is particularly the case 
where a client needs to determine configuration information for a large number of servers on the network. 

Similarly, network managers use network management tools to determine the state of network resources, such as 

55 routers, bridges, printers, file servers, disk drives, workstations and the like. With conventional network management 
tools, such as tools compliant with the SNMP or CMIP standards, individual managed objects are associated with each 
network device. The network manager can query and configure networked devices through manipulation of the man- 
aged object associated with each device. These managed objects however, are limited to conveying information at the 
device level, and do not query or manipulate object level information for individual processes, particularly for servers 
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running on workstations and sinnilar processing units. For exanple. SNMP tools currently do not determine the inter- 
faces implemented by a given server on a particular workstation. Thus, these tools do not provide adequate level of 
granularity for use by a systems administrator of a client-server system built on a distrilxjted object programming envi- 
ronment. 

5 Additionally, SNMP and CMIP tools require the network device associated with each managed object to be operat- 

ing and available on the network in order for the managed object to determine and configure the state of the network 
device. Conventional managed objects are unable to automatically startup their associated network devices, and thus 
if the network device crashes or its othenvise terminated, the managed object and the SNMP tool is unable to provide 
information about the network device. This is because the managed <^jects do not have information about the startup 

10 configuration of the network devices, as the managed objects operate on the assumption that the associated network 
devices are already operating. Thus, these tools would also require the servers to be executing in order for any infor- 
mation to be obtained. Similarly, with low level protocols, like RPC. no information is stored about pathnames, configu- 
ration infornration or the like for servers, again, preventing an RPC agent from starting a networked server, or providing 
process level information. 

15 In conventional systems where the processes aeated by an application all reside in a common address space, typ- 
ical system administrative tools require providing an explicit reference to the host machine and the process or proc- 
esses for which information is requested. In a distributed object programming environment, however, a client invokes a 
server through an object reference, without having information as to where the invoked object resides in the system, 
that is, without specifically knowing the computer where the invoked object is stored or where its running. Rather, the 

20 client passes the ot^ect reference through an object request broker which locates the server, and passes back my out- 
put from the server to the client. To the user, the client and server, and any group of distributed objects, behave trans- 
parently as an integrated application, even though the objects may be distributed in various computer systems. One 
standard for the distributed object programming is the Common Object Request Broker Architecture (CORBA), speci- 
fied by the Object Management Group, In this environment, conventional system administrative tools are shielded from 

25 the actual implementation of the server, and do not have a mechanism for obtaining unified access to the internal struc- 
ture of a server, particuarly its configuration setup. While such information may be available in various objects in various 
parts of the environment, such as naming services, and the like, there is no unified object that provides this information 
access efficiently. 

Accordingly it is desirable to provide a method and system for obtaining and manipulating configuration information 
30 about servers on computers in a distributed object programming environment without starting up the servers, and 
where only an object reference to the server is available to clients. 

SUMMARY OF THE INVENTION 

35 The present invention overcomes the foregoing limitations by associating with each server a persistent stored 
object known as a server administrator. The server administrator stores various types of information that can be known 
about the server without starting up the server, such as its execution definition, name, location, and various internal con- 
figuration information, such as the object interfaces and implementations supported by the server. Because the server 
administrator is persistent, it maintains the configuration information even when the server is not executing. This allows 

40 the configuration information to be manipulated by clients via the server administrator, which also provides various 
methods for changing and updating the configuration information. 

The presence of a server administrator simplifies the discovery of what services the server provides through the 
object interfaces and implementations. In the absence of this information stored in the server administrator, clients 
would have to start up the server to obtain this information. This process can be extremely time and resource intensive, 

45 particularly where a client is attempting to determine this information for every server on the network. Storing interface 
and implementation information in an object, such as the server administrator, external to the server, means that this 
information can be obtained without starting up the server. 

The server administrator also provides for unified storage of startup configuration for the server, allowing a client to 
obtain and manipulate the startup configuration for many different servers by accessing their respective server admin- 

50 istrators which may be stored in a common naming context. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is an illustration of a system of distributed computers for using server administrator objects; 
55 Figure 2 is an illustration of the organization of a host computer supporting various servers; 

Figure 3 is a flowchart one embodiment of a process of registering a server with a persistent assodated server 
administrator object; 

Figures 4a and 4b are data flow diagrams of the call architecture for obtaining information about a server without 
starting up the server; 
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Figure 5 is a flowchart of one embodiment of a process for interposing an application for the server; 
Figure 6 is a flowchart of one embodiment of a process for updating tracing facilities in the server; and 
Figure 7 is an illustration of one embodiment of a user interface for obtaining information about servers and host 
machines. 

HFTAILED DESCRIPTION OF THE PREFERRED EM BODIMENT 

Referring now to Figure 1 there is shown a hardware view of a system 100 for determining and manipulating con- 
figuration information for servers on distributed computers in a distributed object programming environment. The sys- 
tem 100 includes a number of host computers 101 connected along a network 103. Each host computer 101 includes 
secondary storage 107 for long term storage of implementation code and data for servers and clients, and the like, an 
input device 109 and an output device 1 15 for receiving and outputting commands and data into the system 100. and 
an addressable memory 1 13 for storing server and client implementation code during execution by a processor 111. 
During execution by the processor 111. sen/ers exist as processes in the addressable memory 1 1 3. Also coupled to the 
network 103 are a number of clients 105. Each dient 105 is an object executing as a process in a remotely situated 
computer similar in structure to a host computer 101 . or alternatively, existing as separate processes in any of the host 
computers 101. Each client 1 05 requests services or data from servers (not shown) in host computer s 101 on the net- 
work 103. The host computers 101 may be realized by most general purposes computers, such as a SPARCstation™ 
computer manufactured by Sun Microsystems. Inc. of Mountain View. Ca. Any other general purpose computer may 
20 also be adapted for use with the invention. Each host computer 101 executes a general purpose operating system, such 
as Sun Microsystems' Solaris® operating system. In addition, each host computer 101 is part of an object request bro- 
ker environment, satisfying the CORBA standards set by the Object Management Group in The Common Object 
Request Broker: Architecture and Specification, Rev 1.2. OMG TC Document Number 93-12-43. available by anony- 
mous ftp to omg.org. Other equivalent environments for distributed object systems may also be used. In the preferred 
25 embodiment, the object request broker environment is Sun Miaosystems' Project DOE (Distributed Objects Every- 
where). ^ *- X 
Referring now to Figure 2. there is shown a logical view of system 100. particularly illustrating the configuration of 
addressable memory 1 13 in any of the host computers 101 during runtime operation of various servers. The address- 
able memory 1 13 of each host computer 101 includes a number of executable objects for performing various functions. 
30 including user application functions, such as word processing, database management, graphics design. CAD engineer- 
ing, software development, financial management, and the like, and operating system functions, such as memory man- 
agement, resource allocation, storage management, and system accounting information, and network interfacing with 
remote clients and hosts. 

More particularly, host computer 101 includes a number of servers 201. each providing a particular type of func- 
35 tionality to clients 105 distributed on the network 103 (or locally executing in the host computer 101). Each server 201 
in the host computer 101 includes a number of objects 209. each of which encapsulates data associated with the object 
209 and its state, and executable code for implementing functional operations, or methods of the object 209 on the data 
or other objects 209. An object 209 is manipulated by clients 105 or other objects 209 through an interface definition 
that specifies the operations, attributes, and exceptions that an object 209 provides. The objects 209 are distributed 
40 Objects, distinguished from conventional objects in object oriented programming languages in that the interface of an 
object 209 is defined in an interface definition language, which is then mapped to an implementation language, such as 
C-H- or C- This allows objects 209 to have multiple implementations in various languages, while still maintaining a con- 
sistently defined interface. A client 105 does not have to have any information about the underfying implementation of 
the object 209. but merely has to have the interface for the object 209. The objects 209 are distributed in that a client 
105 may invoke an object 209 existing anywhere on the network 103, including in the address space of a client 105. or 
any number of host computers 101, by using a naming server 227 and the various BOAs 225 on the host computers 
101. 

Facilitating communication the clients 105 and the host computers 101 is a basic object adapter 225. or BOA. The 
BOA 225 comforms to the requirements for the basic object adapter specified in CORBA. The BOA 225 provides an 
interface for clients 105 to access object implementations of objects 209 included in servers 201 on various host com- 
puters 101 distributed on network 103. Object implementations are actual code which implements an object 209. In 
order to efficiently manage the addressable memory 1 13 of the host computer 101 , the BOA 225 maintains records indi- 
cating which servers 201 are active and inactive, and in each server 201, which objects 209 are active or inactive, and 
which implementations of object methods are also active or inactive. In this way the BOA 225 can readily manage mem- 
55 ory resources in the addressable memory 1 13 on an as-needed basis, allocating memory to active servers 201 . objects 
209 and implementations, and deallocating memory from inactive entities. The BOA 225 includes a daemon for man- 
aging and responding to invocations from clients 105 for objects 209 in the various servers 201 of the host computer 
1 01 . The daemon of the BOA 225 automatically starts up a server 201 in the host computer 101 to service an incoming 
call to an object 209 if the server 201 is not running. The BOA 225 receives a request from a client 105 for an object 
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209 in a server 201. the drent 105 passing the object reference to the BOA 225. The BOA 225 determines whether 
there is an active implementation of the object 209 or method and if so. the BOA 225 passes the request to the object 
209. otherwise, the BOA 225 retrieves the implementation code for the object 209 from secondary storage 107. starts 
a new process for the invoked ot^ect. executing the inplementation with the processor ill. The BOA 225 will also man- 
5 age deactivation of objects 209 and implementations that are no longer being us^, or that are explicitly ternninated by 
a client 105 or server 201, reclaiming resources allocated to the object 209 and updating any persistent attrilxjtes or 
data of the object 209. 

Coupled to the host computer 101 by the network 103 is a naming server 227. The naming server 227 maintains a 
name space directory 229 including number of naming contexts, each of which includes a set of name bindings. A name 

w binding is an association between an arbitrary otsject name, and an object reference uniquely identifying an object 209 
within a server 201 and further identifying the server 201 . and host conputer 101 including the object 209. The naming 
server 227 provides methods for binding a name to an object reference so that the object 209 associated with the object 
reference can be accessed from the name, and for resolving names provided by clients 105 in order to provide an object 
reference to a client 105. With an object reference, a client 105 can directly invoke a server 201 or any object 209 within 

15 a server 201 . The naming server 227 provides clients 105 with a service that allows access to distributed servers 201 
before the client 105 has an object reference. Multiple naming servers 227 may be supported, with clients 105 trans- 
parently accessing various naming servers 27 on the network 103. In the prefen-ed embodiment, a naming server 227 
is included in each host computer 101 . and supports objects 209 within the host computer 101 ; multiple naming servers 
227 then work in conjunction to provides clients 105 with object references for local objects 209. 

20 A factory object 21 1 may be associated with each object 209. for performing a single method that is called by a cli- 
ent 105 to create a new instance of the type of object 209. The factory object 21 1 is registered in the name space direc- 
tory 229 of the naming server 227. which is accessed by clients 105 for obtaining object references. Each factory object 
21 1 includes a static create member function that creates a new object 209 of the type specific to the factory object 21 1 , 
and returns an object reference to the new object 209. An initialize function is provided in aeated object 209 to perform 

25 any needed initialization on the object's state. Typically there is only one instance of a factory object 21 1 implementation 
for each object 209 in the server 201 . The instance of each factory object 21 1 is created when the server 201 is installed 
in the host computer 201 and registered in the naming server 227, An object 209 need not have an associated factory 
object 21 1 . for example, where the object 209 is not public and available only to the server 201 . or where the server 201 
is designed to have a single instance of a particular type of object 209. 

30 For each server 201 on the host computer 101 there is a persistent server administrator 203 object that is instanti- 
ated from a server administrator class. Each server administrator 203 maintains configuration information for the par- 
ticular server 201 associated with the server administrator 203. including information that can be known whether or not 
the server 201 is executing. This allows system administrative tools to determine the state of the server 201 without 
having to start up the server 201 as a process in the host computer 101. Throughout the remainder of this disclosure. 

35 references to "the server" and "the server administrator" refer to one server 201 and its associated server administrator 
203. and it is understood that the functionality described for these respective entities applies to each respective server 
201 and server administrator 203 in the host computer 101. 

A server administrator 203 is created by a server administrator factory 205 when a server 201 is installed on the 
host computer 101. A server 201 is installed using conventional installation techniques, such as executing the server 

40 201 using the name of the server 201 along with a -install command line argument. During this execution, the server 
201 will create a new server administrator 203. Figure 3 shows a flowchart of one method by which a new server admin- 
istrator 203 is associated with a server 201 , 

First, the server 201 is executed 301 during the installation process. The server 201 searches 303 for an existing 
server administrator 203 object by accessing the naming server 227 for the host computer 101, and traversing the name 

45 space directory 229. The server 201 determines 305 whether a server administrator 203 object exists with the appro- 
priate name. If no associated server administrator 203 object is located in the host computer 101. the server 201 
accesses 307 the server administrator factory 205 via an object reference stored in the naming server 227. 

The server 201 will invoke 309 the create method of the server administrator factory 205. instantiating a new server 
administrator 203 object, and obtaining an object reference for the new server administrator 203. The server 201 will 

50 then store 31 1 a binding of the object reference and an object name for the server administrator 203 in the naming 
server 227; the object name should uniquely identify the server administrator 203 as associated with the particular 
server 201 . Typically the ot)ject name will have the following format: 

(host_computer_name)/admin/servers/(server_name) 
where host_computer_name is the literal string name provided to the host computer 101 including the server 201. and 

55 the server_name is specified by the developer of the server 20 1 . 

The server 201 will set 313 various execution related configuration information in the appropriate structures of the 
server administrator 203. as further described below. This information preferably includes the name of the host conpu- 
ter 101 where the server 201 is installed, the name of the server 201 and any aliases for executing multiple instances 
of the server 201. the path name of any data directory the server 201 uses for storing and accessing local data and 
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resources and the program definition. The data directory information allows the operating system or other administra- 
tive layer to administer the files in the data directory, lor example, providing backup services. The data directory is used 
to issue a change directory command after the server 201 is executed so that the identified directory becomes the cur- 
rent directory The saved program definition is the pathname, command line arguments, and environmental vanables 

5 used when the server 201 Is started up. 

Normally, the program definition is stored in the BOA 225 as a part of the execution definition. In the BOA 225. any 
change to the program definition is permanent and undoable. and thus previous configurations of the program definition 
are not saved However, it is typically necessary to alter the program definrtion for administrative reasons, for example, 
to attach a debugger to the server 201 for debugging, or to execute various functions from a shell program. Convention- 

.0 ally once the program definition in the BOA 225 is made to accommodate these needs, the system administrator would 
have to manually reconstruct and reset the normal or original program definition. With the saved PfOQ^am de^^itran 
stored in the sen/er administrator 203 this information can be preserved and recalled separately from the BOA 225. The 
saved program definition thus allows the server administrator 203 to restore the correct program definition after the BOA 

Once th^bS^rver information is stored in the server administrator 203, the server 201 will loop 315 over each 
of the implementations present in the server 201 . Each implementation is executable code that implements an interface 
for methods or attributes of an object 209 included in the server 201 . The server 201 tests 317 whether the interface of 
the implementation is already stored in the server administrator 203, and H not. the server 201 stores 319 to the server 
administrator 203 information to identify the interface. This information preferably includes an identification of the inter- 
face such as the name of the interface and an identification value. This information allows the server administrator 203 
to provide to clients 105 information as to which objects 209 the server 201 supports. The server 201 then stores 321 
in the server administrator 203 information about the implementation, preferably storing the name of the implementa- 
tion and an identification value of the implementation that is unique on the host computer 1 01 . and the interface asso- 
ciated with the interface. This allows the server administrator 203 to invoke the implementation at a later time in 
25 response to a request from a client 105. thereby starting up the server 201 if necessary. 

The purpose of this loop is to identify to the server administrator 203 which object interfaces the server 201 imple- 
ments so that the server administrator 203 can provide this information to client 105 at a later time without having to 
start up the server 201 if it is not running at the time the client 105 requests the information. In addition, this internal 
information which is otherwise not directly available to clients 105 because of the location opacity of ttie distributed 
30 object programming environment, allows clients 105, acting on behaH of system administrators or others, to determine 
which servers 201 are capable for performing which functions. 

The server administrator 203 provides clients 105 with a unified means for accessing and manipulating configura- 
tion information about the server 201 witti which it is associated. Figure 4a illustrates a dataflow diagram of the basic 
architecture of obtaining and manipulating configuration information. Generally, the server administrator 203 receives 
401 a request from a client 105. ttirough an invocation of one of its operations or attributes, for selected configuration 
information about the server 201. The server administrator 203 will execute 403(a,b) the appropnate method, as 
requested by the client 105 to manipulate the information. The server administi-ator 203 may then return 413 the infor- 
mation to the client 105 if requested. ^ . J ^- 

More particularly the server administrator 203 may invoke 403a a method to return 405 tine requested configuration 
information from various sources. These include returning 405a the configuration information by accessing stored 
structures 411 in the server administrator 203 that persistentiy maintain the configuratfon information: by accessing 
405b configuration information stored in the BOA 225; and by accessing 405c the server 201 itself. 

The server adminstrator 203 may also execute 403b methods to update 407 configuration information using values 
or data supplied by the client 105. These methods including updating 407a the stored configuration information 411; 
45 updating 407b persistentiy stored configuration information in the BOA 225 or similar services; and updating 407c 
stored configuration information in the server 201 . . . ^ j- x . j 

In some instances, tine server administrator 203 may also invoke 409 other objects 209 or services in ttie distributed 
object environment to obtain tiie requested configuration information. ^ c 

Where the server administrator 203 accesses the stored configuratfon information 411. tine BOA 225. or other 
50 object 209 it performs its functionality without invoking the server 201 H the server 201 is not already executing as a 
process in the host computer 101. This conserves system resources, provides faster response time to dient 105 
requests, and simplifies administi-ation of tine system 100. 

Referring generally to Figure 2. for those methods that obtain dynamic conf iguration information, such as the proc- 
ess identifier of the server 201 . there is preferably an object 209 within the server 201 tiiat can observe and report the 
55 current state of the server 201 . Because the server administrator 203 is not within the server 201 with which it associ- 
ated it must call an object 209 that is. In order to ensure that the server administrator 203 always has access to the 
same object 209 in a server 201 regardless of how the applications developer created the server 201 . there is preferably 
embedded in each server 201 a server spy 213 object. The server spy 213 object is more completely deswibed in the 
related applicatfon identified above. The server spy 213 is known by the server administrator to always be present, and 
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acxxjrdingly. the server administrator 203 calls the server spy 213 to otrtain dynamic configuration information about the 
server 201 containing the server spy 213. The server spy 213. as with all objects 209. inherits from a base class. 
CORBA:Object. that provides several fundamental functions. One of these is the Jnplementation method. This 
method returns a CORBA pseudo object specific to a CORBA defined implementation dass. This class provides further 

5 basic functionality, particularly, methods that return information about the process in which the originating object, here 
the server spy 213. is en±>edded. This information is passed back to the server administrator 203 as necessary to pro- 
vide the desired information to a requesting dient 105. 

Figure 4b illustrates the general architecture of this interaction between the server administrator 203 and the server 
spy 213. First, a dient 105 will invoke 401 a method of server administrator 203 to provide some specific information 

10 about the cun-ent state of dynamic configuration information of the server 201 . The server administrator 203 will invoke 
415a the server spy 213 to obtain the information. In some cases, the server spy 213 has the necessary method to 
obtain the information, and so executes and returns 417a this information to the server administrator 203. In other 
cases, where the server spy 21 3 does not indude an appropriate method itself, server administrator 203 will then invoke 
415b the Jmplementation method of the server spy 213. The Jmplementation method is inherited from the 

15 CORBA::Object dass. and returns 417b an object reference to a CORBA pseudo object 419. This CORBA pseudo 
object 419 has all the functionality defined by the CORBA standard for the object base class. The server administrator 
203 will then invoke 415c an appropriate fundion call on the CORBA pseudo object 419 to obtain the requested infor- 
mation about the server 201 . The CORBA pseudo object 41 9 will return 41 7c this information to the server administra- 
tor 203. which may store it 407 or pass it 41 3 on to the dient 1 05 if desired. In other cases, the server administrator 203 

20 will invoke 415a a particular method of the server spy 213. which will in turn invoke or access 423 a lower level object 
or process, such as the operating system 421 or the BOA 225 to obtain the requested information. 

This architecture has been shown with respect to the preferred emlxxJiment using the server spy 213. The server 
spy 213 is the preferred object 209 for this process because it is embedded in every server 201 created in the distrib- 
uted object programming environment, and thus, the server administrator 203 can reliably invoke the server spy 213 in 

25 the server 201 . Alternatively, any object 209 in the server 201 can be employed in the same capadty as the server spy 
213. so long as that object 209 inherits from the CORBA::Object dass. To do this, the server administrator 203 would 
have to identify the objects 209 in the server 201. in a manner similar to that described with respect to Figure 3. The 
server administrator 203 could then select one of the identified objects 209 as its agent for performing these various 
methods as required. 

30 The specific methods or attributes provided in the preferred embodiment of the server administrator 203 for deter- 
mining various types of configuration information of the server 201 are as follows, and are one implementation of the 
interface definition induded in Appendix A. Appendix A is a pseudo interface definition language (IDL) file illustrating 
one emtxxJiment of the interface of the server administrator 203; the following discussion is with respect to the function- 
ality of a server administrator 203 described above, as provided by the interface disclosed in Appendix A. It is under- 

35 Stood that other interface definition files may also be suitably used to define a server administrator 203 object. Similarly, 
various inplementation files can be used to implement the attributes of the server administrator 203 (further described 
below) as shown in IDL file. 

The server administrator 203 includes an attribute for determining whether the server 201 is currently executing as 
a process in the processor 1 1 1 of the host computer 101 . An example of the interface for this attribute is the is_running 

40 attribute of the IDL. This boolean attribute indicates whether the server 201 assodated with the particular server admin- 
istrator 203 is currently executing as a process by the processor 1 1 1 of the host computer 101. When this attribute is 
invoked, the server administrator 203 calls 415b the Jmplementation method of the server spy 213. as illustrated in Fig- 
ure 4b. which returns 417b an object reference to a CORBA pseudo object 419. 

The server administrator 203 then invokes 415c an is_server_running method on the CORBA pseudo object 419. 

45 which is provided as part of the implementation objed class for CORBA. This method operates by determining whether 
the implementation that includes the CORBA pseudo object 41 9 is currently executing. The CORBA pseudo object 41 9 
will return 417c a tK)olean TRUE if the server 201 is running, othenwise, it returns 417c a boolean FALSE. With this 
method, the server administrator 203 is able to determine, on behalf of a request from a client 105. whether a server 
201 is adually running without starting up the server 201 since a call to the CORBA pseudo object 419 may be com- 

50 pleted without starting up the server 201 . as with a normal distributed object 209. 

The server administrator 203 further includes an attribute for determining the process identifier of the server 201 . 
An example of the interface for this attribute is the process Jd attribute of the IDL This attribute is implemented by 
method similar to the is_running attribute. Here, after obtaining 417b the objed reference to the CORBA pseudo object 
419, the server administrator 203 will invoke 41 5c a process Jd method on the CORBA pseudo object 419. This method 

55 returns 417c the process identifier for the process, here the server 201 process, that contains the CORBA pseudo 
object 419. If the server 201 is not running as a process, the CORBA pseudo object 419 will return zero. Again, this 
method allows the server administrator 203 to provide internal state information, here the process id. of a server 201 to 
a dient 105 without starting up the server 201 . 
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The server administrator 203 further includes an attribute which will suppress the server 201 from starting up to 
semce invocations of object 209 within the server 201 An example of the interface for this attribute is the hold down 
attribute of the IDL As noted, the daemon of the BOA 225 automatically starts up an inactive server 201 in the host 
computer 101 to service an incoming call to an object 209. However, it is sometimes desirable to suppress the server 
201 for example, to upgrade, or backup the server 201 . In these instances, the system administrator or other user does 
not want the daemon to start up the server 201 in response to calls from clients 105. Accordingly, t^je cteemon wiH 
always check a hold down value set in the execution definition of the server 201. as stored in the BOA 225. The 
hold down attribute (Tn both the server administrator 203 and in the BOA 225) is preferably a mu tivalued enumerated 
ivpe'providing for various types of hold.down responses. The hold.down attribute may have a LONG value, which 
iSicates to the daemon that the server 201 will be down for an extended period time. In this case, t^^^ <tee";.°"J^^^ 
throw an appropriate exception back to the invoking client 105. The hold.down attribute may have a SHORr value 
indicating the the server 201 will be down only temporarily, such as several seconds, in which instance the daemon will 
wait until the server 201 is available again, and then service the client 105 by starting up the server 201 . Finally, the 
hold down attribute may take a "NONE" value, indicating that the server 201 is not held down, and .mrried.a ely ava|la- 
ble for execution. The server administrator 203 sets the hold.down attribute by finding the execution definition for tt^e 
server 201 in the BOA 225. obtaining the program definition included in the execution definition, and setting the 
hold_down value in this definition. 

The server administrator 203 further includes an attribute that stores a master version of the program definition in 
the BOA 225 An example of the interface for this attribute is the boajrogram.def attribute of the IDL. This program 
definWon includes the pathname, command line arguments, and the environment to be used when the sen/er 201 is 
started up by the BOA 225. This attribute of server administrator 203 allows a client 105 to change the program defini- 
tion at any time, again, without having to start up the server 201 merely for this purposes, and wrthout having to directly 
interlace with the BOA 225. This is down by invoking the boajjrogram_def attribute and passing in the desired param- 
eters Once changed, the new program definition will be used by the BOA 225 the next time the server 201 is invoked. 
When this attribute is invoked without parameters, the server administrator 203 will return the current program defini- 

The server administrator 203 further includes an attribute that stores a backup version of the program definition in 
BOA 225 An example of the interface for this attribute is the saved jrogram_def attribute of the IDL. As described 
above the BOA 225 only maintains a single current program definition, which may be changed only temporarily for 
administrative purposes. The saved program definition allows changes to the program definition to be restored to a pre- 
vious version- this is particularly useful for temporary changes to the program definition. Invoking this attribute returns 
the current saved program definition stored in the server administrator 203. The save program definition is updated 
manually by the server 201 by passing in the program definition when the server 201 is installed. 

The server administrator 203 further includes an attribute that restores the program definition in the BOA 225 with 
the saved program definition of the server administrator 203. An example of the interface for this attribute is the 
restore saved program attribute of the IDL. When invoked, the server administrator 203 will locate the program defini- 
tion of the server 201 in the BOA 225. and save to it the values in the saved program definition attribute. This is done 
bv accessing the BOA 225 using an object key provided by an object key method included in all CORBA objects, such 
as the server spy 213 The object key is then used to extract an object definition, which in turn is used to obtain an 
implementation definition, and finally, an execution definition, including the program definition. Again, the server admin- 
istrator 203 is able to alter this configuration information of the server 201. without having to start the server 201. 

The server administrator 203 further includes an attribute to allow a system administrator to interpose another 
application or server for the sender 201 that the server administrator 203 manages. Interposing allows the system 
administrator to have the daemon of the BOA 225 invoke a debugger, shell program, or other administrative tod when 
the server 201 is invoked by a client 105. by substituting the pathname and argument list of the desired application for 
the server 201 This is one way in which the program definition of the BOA 225 may be changed, as described above 
with respect to the boa _program_def and saved j3rogram_def attributes. Using the Interpose attribute of the server 
administrator 203 allows a system administrator to alter the configuration information of the server 201 without starting 

"one^meth^crffor implementing the interpose attribute is shown in the flowchart of Rgure 5. The interpose method 
is invoked 501 on the server administrator 203. with parameters for the alternate pathname of the interposing applica- 
tion to be executed, and any additional arguments to be passed at the command line. The server administrator 203 
obtains 503 the existing program definition of the server 201 from the BOA 225. and changes 505 the pathname stored 
in the program definition to the pathname of the interposing application. As stated above, the program definition of the 
: server 201 may include a number of arguments to be included when the server 201 invoked. These arguments may not 
be appropriate to the interposing application. Accordingly, the server administrator 203 will restructure 507 the argu- 
ments in the program definition as needed to ensure the correct and useful execution of the interposing application. In 
the preferred embodiment, this restructuring 507 includes the following: setting 509 the first argument of the program 
definition argument to a special string that can be easily recognized as the correct executable path of the interposing 
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application, instead of as a regular argument so that the actual following arguments can be id^tified; setting 51 1 the 
second argument to the actual pathname of the server 201 ; appending 513 the original arguments of the program def- 
inition for the server 201; and finally, appending 515 the additional arguments that were passed into the interpose 
method for controlling the execution of the interposing application. The server administrator 203 will then store 517 the 

5 new program definition in the execution definition of the server 201 in the BOA 225. 

The server administrator 203 further includes an attritxJte for storing and setting the configuration of the reaper 21 7, 
for performing automatic deallocation of resources held by idle objects 209. An example of the interface for this attrilxite 
is the reaper_conf ig attribute of the IDL. The reaper 21 7 is preferably configured by three values, a server timeout value, 
a cycle time value, and a boolean flag. The reaper cycle time determines how often tiie reaper 217 is activated to per- 

w form automatic deallocation. The server timeout value establishes maximum time interval which the server 201 may be 
idle, that is. during which no object 209 within the server 201 is invoked. If this time interval is 

equaled or exceeded, then the reaper 217 will automatically shutdown the server 201 the next time the reaper 
217 is active. The boolean flag, reaping, tells the reaper 217 whether or not to perform automatic deallocation. The 
method of the reaper 217 is further shown in the related application identified above. In the prefen-ed embodiment. 

15 these various values are stored persistentiy in the server administrator 203. and when a server 201 is invoked, the 
reaper 217 included in the server 201 reads the reaper configuration attribute of the server administi-ator 203 associ- 
ated with the invoked server 201, and sets its values accordingly. 

The server administrator 203 further includes an attrilxite for storing and setting the configuration of the logging 
configuration of the server 201 . An example of the interface for this attribute is the l-oggingConfiguration attribute of the 

20 IDL. The logging configuration attribute includes a boolean flag to indicate whether tracing and similar output informa- 
tion is handled by the operating system's system logging daemon; another boolean flag to indicate whetiier such infor- 
mation is to be output to the console, and a structure identifying a user specified log file for outputting this tracing 
information, a number of swap log files, and a maximum file size for the log files. The manipulation of log files is further 
desaibed in the related application referenced above. In the preferred embodiment, these various values are stored 

25 persistently in the server administrator 203, and when a server 201 is invoked, the logging API 221 of the server 201 is 
configured according to the logging configuration of the server administrator 203. 

The server administrator 203 further includes an attribute that maintains various internal event driven state varia- 
bles for the current process of the server 201. An example of the interface for this attribute is the startingQ method of 
the IDL file. In the preferred emtxxJiment. these internal state variables are used to monitor whether the server 201 is 

30 currently running, thereby allowing ttie server administi-ator 203 to report on the current status of the server 20 1 witinout 
starting up the server 201 if it is not already running. These internal state variables include the process identifier for the 
server 201 process, and a heartbeat interval value indicating how often the server 201 sends a signal, a heartbeat, to 
its server administrator 203 indicating that it is still active. This heartbeat signal is preferatHy used instead of the server 
administrator 203 polling the server 201 to determine whether it is active. The internal state variables further include a 

35 value indicating a maximum number of heartbeat signals the server 201 can fail to pass to the server administrator 203 
before being presumed to have crashed. Invoking the starting attribute of the server administrator 203 will cause the 
server 201 to update the attribute values. In the preferred emtxxliment. the process identifier is provided by the server 
spy 213. which indirectly invokes a get_pid() on the server 201 process. 

Each time the server 201 sends a heartbeat signal, the server administrator 203 timestamps the signal. The server 

40 administrator 203 periodically, according to the heartbeat interval value, and determines if the server 201 has missed a 
heartbeat, whereon the server administrator 203 increments a counter. When the counter reaches the maximum value 
set for missed heartbeats, the server administi-ator 203 begins a thread to check whether the server 201 has been shut- 
down or othenwise been terminated. 

In conjunction with the starting method, the server administrator 203 also includes a method that is invoked in 

45 response to a received heartbeat from the server 201. An example of the interface for this method is the 
sending_heartbeat() method of the IDL file. When the server 201 sends a heartbeat, the server administrator 203 
resets a stored timestanop value that ti-acks the time of tiie last heartbeat- If the server administrator 203 itself has 
recently been terminated or shutdown, then it may not have any information as to the identity of the server 201 sending 
the hearti3eat signal; in this case, the server administrator 203 will return a FALSE signal to the server 201 , which in 

50 turn will invoke the startingQ method of the server administrator 203. If the server administi-ator 203 has been active, 
and does have cun-ent information on tiie identity of the server 201 it is assodated with, tiien it return a TRUE signal to 
the server 201 , indicating that the heartbeat has been successfully received. 

Finally, the server administi-ator 203 also includes an method that is used to indicate that the server 201 has been 
shutdown. An example of the interface of this method is the stoppingQ method of the IDL file. When the server 201 is 

55 shutdown tiirough the shutdown method of the server spy 213. the stopping() method is invoked. This updates ttie inter- 
nal state variables of the server administi-ator 203 to indicate ttiat the server 201 is no longer active. 

The server administrator 203 further includes a number of methods for configuring the tracing facilities included in 
a server 201. A tracing facility is a set of trace flags that control tracing of selected events, and a set of output values 
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that are output when the various traced events are executed. Tracing facilities and their use are described in further 
detail in the related application. . 

A trace configuration is a set of tracing facilities. The server administrator 203 can store a '"^'^^'^''^^^l^Z 
figurations that can be used with the server 201 to provide for conditional output of tracing mformalon^ When the server 
201 Ss^rte^ ulJ. it reads the tracing configuration information in the server administrator 203. and selects a d,stn- 
guished tracing figuration for initial use: this tracing configuration is named "startup." The f 
Sn la^ change the setup for available tracing configurations, by selecting conf-gurations that prov.de different sets of 
See fadlSs or enabling or disabling various trace flags in selected trace facilities. This process does not change the 
a^al fSitiesIn thfse'er 201 . but only the settings of the fadlHies that will be used if and when the faclrty -s later 
enabled in the server 201 . The server spy 213 is used to enable or disable the tracing facilities m the server 201 . 

MorrspecmcLlfy. the sen/er administrator 203 includes various methods for determining and changing tracing con- 
figurations A find method allows a user, such as a system administrator operating through a client 105. to locate a spe- 
Sic Sg conf juration by name, enabling the user to determine if such a facility is present in the server administrator 
203 If the named configuration is not present, the server administrator 203 returns an appropnate exception. 

An add method allows a system administrator to add a new. empty configuration with a specified name to a server 
201 to be later completed with specified facilities. When invoked, server administrator 203 will search for the named 
coiiguration tn itsl^red sequence of configurations. If the configuration is found the server ^dm-nistrator 2^^^^^^ 
return an exception indicating its existence, otherwise, the server administrator 203 will create a new configuration. A 
[emJIie meS allows a sysL administrator to remove a named configuration from the stored sequence of configu- 

'^*'°The server administrator 203 also includes a method for enabling specific trace flags in a trace facility in a config- 
uration. The user passes in a configuration name, a trace facility name, and the desired flags to be enabled. The server 
administrator 203 will search through its stored sequence of configurations. If the named corfiguration ,s found^^e 
server administrator 203 will search through the configuration for the named faal.ty. and if this facility is included in the 
coSation. the server administrator 203 will enable the desired flags. The server adminis^ator 203 w- rjum Wo- 
priate exceptions if either the configuration or fadlity is not located. Similarly, the server administrator 203 mdude^^^^ 
method for disabling specific trace flags in a user identified trace configuration and trace facility. Examples of the inter- 
faces for the add, find, remove, enable and disable methods are shown in the IDL file. 

The server spy 213 indudes methods for altering the runtime operation of tracing facilities in the server 201. 
Accordingly, during the life of the server 201 process, the tradng fadlities in the server ^^ministrator 203 may dep^^^^ 
from those operating in the server 201 . with new fadlities added, or dd ones deleted in the server adminis rator 203^ 
T^e server administrator 203 thus includes a method for updating the server 201 to include the current set of trac ng 
facilities in the server administrator 203, by deleting from the server 201 tracing faalities that are not current y in the 
server administrator 203. and by adding fadlities that are present in the server administrator 203 but not currently avail- 
able in the server 201 . An example of interface for this method, set_fadlities. is shown in the IDL file. 

Figure 6 is a flowchart of one embodiment of the logic of a method for updating the facilities of the server 20 1 In 
this errtKXliment, the method loops 601 over each of the facilities in the server administrator 203. and or each facility, 
o^ps^overthe fadlities in the server 20l.lf none of the fadlitiesin the serv^^ 

administrator 203. then the fadlity is added 607 to tine server 201 . This part of the method updates the server 201 to 
includeany new fadlities defined in thesen/er administrator 203. Second, the method looF«M9ov^ 
sen/er 201 . and over 61 1 each fadlity in the server administrator 203, and determines 613 ^'h^ther the server 201 facil- 
ity is present in the server administrator 203. If not. then the facility is no longer required, and rt isdeleted 615 from the 
server 201 . The method then retorns 61 7. Alternate implementations of the setjadlities method may be employed with 
variant loop structures, or processing steps. _ om 

In the preferred embodiment, the set_fadlities method is called by the server spy 213 when the server 201 is reg- 
istered with the BOA 225 to update the facilities in the server 201 with flie set of tradng fadlrt.es maintained by the 
server administrator 203. This sets the sen/er 201 to use the most current tracing configuration. 

The various methods induded in the preferred embodiment of the server administrator 203 Pro^«le acc^a"^ 
manipulation of detailed configuration about the server 201. Because the server administrator 203 IS persisten^^ 

ious types of configuration information are maintained beyond a given execution of the server 201 Because the server 
administrator 203 is external to the server 201 , its information can be accessed and manipulated without smarting up the 
sen/er 201 . This is benef idal to system administrators and clients 105 for determining the status of many different serv- 
ers 201 on the network 103 at a time. „W^,««r, 
For example. Figure 7 shows one possible embodiment of a user interface for accessing configuration information 
I of the type described herein for servers 201 . Here a window 701 provides a column 703 listing the availatte host cam- 
puters 101 . a column 705 for the available servers 201 on a each host computer 101 . a column 707 listing the the obied 
implementations provided by each server 201. and a column 709 for the process identHer of eadi server 201. if ttie 
sen/er 201 is active. For example, the Sales.Order server 711 is available on host computer "bagua. and provides 
object implementations 713 for a SalesOrderFactlmpl object, a SalesOrderlmpI object, and a ServerSpylmpI ob)ect. As 
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shown in column 709. this server 201 is not currently executing. Other servers are active, such as the 
Warehouse_server 715. and the process identifier is the same for all its implementations. The window 701 allows a 
user, such as a system administrator to filter the listing, using either a host computer name in text entry field 71 7, or a 
server name in text entry field 719, or both. As can be seen by the listing, servers 201 can be identified in host comput- 
5 ers 101 witfiout starting them up. as indicated by the "inactive" notation for the process identifier, 

APPENDIX A 

// File: ServerAdmin. idl 
// 

// ® 1994 Sun Microsystems, Inc. 
// 

ftifndef _SERVER_ADMIN_IDL 
# define _SERVER_ADMIN_IDL 

// ^pragma idenc "0 (#) Serve r Admin . idl 1.13 95/01/16 Sun Microsystems- 

iinclude "ServerSpy . id!" 
25 

// 

// Each ODr server has a ServerAdmin object associated with it that 
// has static information about a server, that is. everything that 
20 be known without the server process running. 

// 

//It also implements the ServerSpy interface, which includes calls to 
// inspect and change the state of the running server. 
35 // 



}5 



module DatFxt { 

// Interface. The interface ID is the logical ID used in the interface 
/! repository, 
struct Interface ( 

string interface_nair:e; 

string interf ace_id; 

45 

); 

typedef sequence<Interf ace> Interfaces; 

so f f Implementation of an interface. The iclass_id is the internal 

// identifier of the implementation, \inique on the host, 
struct Implementation { 

Interface implemented_interface; 
55 string imple:nentation_nsune; 

BOA: : Iclassid iclass_id; 
Datint :: Seconds reaper_timeout ; 



11 



EP 0 732 834 A2 



}; 

typedef sequence< Implemencation> Implementations; 

5 

/ / Psi implemented interface, 
struct Imp leraentedlnter face { 

Interface implemented_inter f ace ; 

10 

Implementations implementations; 

}; 

typedef sequence<lmplementedlnterface> Implementedlnterf aces ; 

15 

if Named tracing configurations. There is always a configuration named 

// "startup" which is read by the server when it starts. 

// To change the current tracing without saving anything permanently, 

// use the calls inherited from ServerSpy which operate directly on the 

// running server process. 

struct TraceConfig ( 

string config_name; // Config's name 

25 Datint : -.Facilities facilities; // Facilities and their flags 

); 

typedef sequence<TraceConf ig> TraceConf igs ; 

ZO interface TraceConf igList { 

exception ConfigExists {}; 
exception UnknownConf ig {); 

exception Predef inedConf ig {}; // Trying to remove "startup", etc. 

35 

void add( 

in string config_name 
) raises (ConfigExists) ; 

40 

void remove ( 

in string conf ig_naine 
) raises (UnknownConf ig. Predef inedConf ig) ; 

45 

TraceConfig f ind( 

in string config_name 
) raises (UnknownConf ig) ; 

SO 

void use( // Use this config for current tracing 
in string config_name 
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) raises (UnknownConfig) ; 

void enable_flag( 

in scring conf ig_nanie, 
in sCring facilicy_naine, 
in scring flag 
) raises (UnknownConfig, 

Datint: :ServerSpy: :UnknownFacility, 
Datint: :ServerSpy: : UnknownTraceFlagJ ; 

void disable_flag( 

in string conf ig_name, 
in string f acility_naitte, 
in string flag 
) raises (UnJcnownCon fig » 

Datint: :ServerSpy: :UnknowTiFacility, 
Datint: :ServerSpy: :UnknownTr ace Flag) ; 

boolean f lag_is_enabled ( 
in string conf ig_ncune, 
in string facility_name, 
in string flag 
) raises (UnknownConfig, 

Datint: iServerSpy: :UnknownFacility, 
Datint: :ServerSpy: : UnknownTr ace Flag) ; 

readonly attribute TraceConfigs trace_conf igs ; 

// These two are for internal use only, 
void set_facilities ( 

in DatXnt: : Facilities facilities 

) ; 

void destroy ( ) ; 

); // TraceConf igList interface 

// Startup logging configuration, 
struct LoggingConfig { 

boolean send_to_syslog; // Send output to syslog daemon? 

boolean send_to_console; // Send output to console (ie stderr)? 
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Dacinc : -.LogFiLs log_fHe; // Send output to this file 

); 

// Startup reaper conf igr^racion . Each implmentation* s reaper timeout 

// is set at startup from the corresponding Implementation 

// structure. 

struct ReaperConfig ( 

// How many seconds to wait after the last object invocation 

Datint: : Seconds server_timeout ; 

// How often to wake up the reaper thread and check timeouts 
Datint: : Seconds reaper„cycle_time; 
// Whether reaper should be started 
boolean reaping; 

); 
// 

// Internal Admin interface 
// 

// These are the methods that should only be called from within ODF. 

// 

interface InternalAdmin { 
void set_server_name ( 

in string server_naiue 

) ; 

void set_version( 

in Datint :: Version version 

) ; 

void s et_data„di rectory ( 

in string data_directory 

) ; 

void set_computer_name( 

in string-computer_naine 

) ; 

void set_development_mode ( 

in boolean in_development 
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// 

// Populate the interface/ implementation sequences: 

// servers at registration time 

// 

exception InterfaceExists (); 
exception Inter faceNotFound (); 
exception ImplementationExists (J; 
exception ImplementationNotFound {); 

// Called at the start of the registration run 
void clear_interfaces () ; 



Interface find_interface ( 

in string inter face_nanie 
) raises ( Inter faceNotFound) ; 

void add_interface( 

in Interface new_interface 
} raises { InterfaceExists ) ; 

void clear_implementations () ; 



Implementation f ind_implementation ( 

in string inter face_name, 

in string implementation_name 
) raises (IncerfaceNotFound, ImplementationNotFound); 

void add_implementation( 

in Implementation implementation 
} raises (ImplementationExists, InterfaceNotFound) ; 

void set_spy( 

in Datint: :ServerSpy spy 

); 

); // InternalAdmin interface 



// 

// ServerAdmin interface 
// 
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IS 
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30 



40 



50 



55 



in 



interface ServerAdmin: Interna lAdmin, Datint : rServerSpy { 

// 

// Attributes set at server registration time 
// 

// ODF servers automatically set this information, 

readonly attribute string server.name; // Server name 

readonly attribute Datlnt :: Version version; // Server version and date 

readonly attribute string da ta_di rectory; // Persistence directory 

readonly attribute string computer_name; // Where installed 

readonly attribute boolean in_development ; // Versus deployed 

readonly attribute Interfaces interfaces; 

readonly attribute Implementations implementations; 

readonly attribute Implementedlnterfaces implemented_inter faces ; 

// 

// Inspect/change the current server state (also see the ServerSpy 
// interface) 

// 

//Is the server currently running? 
readonly attribute boolean is_running; 

// Process ID if running, zero otherwise 

readonly attribute Domf Administration :: pid_t process_id; 

// Prevent or allow new requests from starting the server. 
// HoldDownDuration meanings: 

// LONG: Future requests throw an exception 

// SHORT: Future requests wait for server to be released 

// NONE: No hold is in effect 

attribute BoaDbAdmin :: HoldDownDuration hold_down; 

// Program definition that controls how the domf daemon starts the 
// server. 

attribute BOA::Program boa_program_def ; 
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// Saved version of server startup parameters in the BOA database, 
attribute BOA: : Program saved_program_def ; 

// Set the current BOA program definition to the saved definition, 
void restore_saved_program( ) ; 

// Interpose another program before the server. - i>rogram_path will 
// become the pathncime, argv(lj becomes "-_orig_prog_path' . 
// argv(2J becomes the original path, and the rest of the arguments 
// are appended. When the domfd starts the server it puts its 'own 
// arguments first, so the interposing program must search for the 
// •-_orig_prog_path" switch to find the server program path, 
const string interposed_arg_identif ier = *-_orig_prog_path" ; 
void interpose ( 

in string alternate_program_path, 

in BoaDbAdmin: :BoaDb: :StringSeq additional_arg3 

) ; 
// 

// Configurations read by servers at startup time 
// 

readonly attribute TraceConf igList trace_conf ig_list ; 
attribute ReaperConfig reaper_conf ig; 
attribute LoggingConf ig logging_conf ig; 

// 

// Methods called by servers to notify ServerAdmin of state changes 
// 

// Called by servers when starting 
oneway void starting ( 

in Domf Administration: :pid_t pid, 

in Datint: : Seconds heartbeat_interval_seconds, 

in unsigned long missed_heartbeats_al lowed 

); 

// Called by servers periodically 
boolean sending_heartbeat ( ) ; 
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// Called by servers when shutting down 
oneway void stopping(); 



// 

70 // Other methods 

// 

// The spy objref . Any calls to this will start the server if it is 
// not already running. 

readonly attribute Datint: rServerSpy spy; 

// Destroy the instance and free its persistent state, 
void destroy ( ) ; 

25 // This interface* s version 

readonly attribute Version admin_interface_version; 
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): // ServerAdmin interface 
// 

// ServerAdminFactory; Create a new ServerAdmin instance 
// 

interface ServerAdminFactory { 
ServerAdmin create ( ) ; 
}; 



#endif // _SE:RVER_ADMIN_IDL 



55 

Claims 

1 . A computer system for accessing and manipulating configuration information about a server without starting up the 
server as a process, comprising: 
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at least one persistent server administrator object associated with the server, and stored externally to the 
server, and including: 

a plurality of nnachine readable storage structures adapted to contain configuration infornnation of the server; 
5 a plurality of nnachine executable structures adapted to access and manipulate the machine readatJe storage 

structures, the machine readatJe storage structures updated to include selected configuration information dur- 
ing registration of the server. 

The computer system of daim 1 further comprising: 

at least one client object executing as a client process: 

wherein the server administrator object is adapted to receive invocations of the machine executable struc- 
tures from a client object, and in response to the invocations, to provide selected configuration information to the 
client object. 

The computer system of claim 1 further comprising: 

at least one client object executing as a client process: and 

a t^sic object adapter communicatively coupled between the client object and the server and adapted to 
provide the client object access to objects within the server, the t^sic object adapter further adapted to store exe- 
cution configuration information of the server to invoke the server in response to a request from the client object: 

wherein the server administrator object is adapted to receive invocations of the machine executable struc- 
tures from a client object, and in response to the invocations, to update the execution configuration information of 
the server stored in a basic object adapter. 

4. The computer system of one of claims 1 to 3. further comprising: 

25 

a primary storage adapted to store the server as a server process including objects and data: and 

a processing unit adapted to execute a server and object methods, each executed server or object method 

being a process in the primary storage: 

30 5. The computer system of claim 4. wherein selected ones of the structures of the server administrator object further 
comprise: 

a process identification structure adapted to determine a process identifier of the server executing as a process 
by the processing unit without invoking the server if the server is not currently executing: and. 
35 a structure adapted to store the process identifier. 

6. The computer system of claim 1 . wherein selected ones of the structures of the server administrator object further 
conrtprise: 

<o a name structure adapted to determine a name for the server, and a structure adapted to store the name; 

a host name structure adapted to determine a conputer name of the host computer including the associated 
server, and a structure adapted to store the computer name: and 

an execution definition structure adapted to determine an execution definition structure containing at least a 
current pathname for the server, and a structure adapted to store the execution definition. 

45 

7. The computer system of claim 6. wherein the execution definition structure is further adapted to establish a current 
program definition including a current set of command line arguments and a current set of environment parameters 
to be used with the server when the server is executed, and is coupled to a structure adapted to store the current 
program definition, 

50 

8. The computer system of claim 7, wherein selected ones of the structures of the server administrator object further 
comprise: 

a structure adapted to store a saved program definition for the server, the saved program definition including a 
55 backup pathname of the server, a backup set of command line arguments, and a backup set of environment 

parameters: and. 

a structure adapted to restore the current program definition with the saved program definition. 
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9. The computer system of claim 6. wtierein the execution definition structure is further adapted to determine a- 
pathname of a data directory associated with the server. 

10. The computer system of claim 1. wherein selected ones of the structures of the server administrator object further 
5 comprise: 

a structure adapted to determine whether the server associated with the server administrator is executing as 

a process without invoking the server if the server is not currently executing; and. 

a structure adapted to store a boolean value Indicative of whether the server is executing. 

TO 

1 1 . The corrputer system of claim 1 , wherein selected ones of the structures of the server administrator object further 
comprise: 

a structure adapted to establish a hold down value in an execution definition of the server used to invoke the 
15 server; and. 

a structure adapted to store the hold down value. 

12. The computer system of claim 1 . wherein the machine executable structures of the server administrator object fur- 
ther comprise: 

20 

a structure adapted to interpose an executable application for the server when the server is invoked; and. 
a structure adapted to store a program definition for the executable application, including a pathname for the 
executable application, and a set of command line arguments. 

25 13. The computer system of claim 1 , wheran: 

the server further includes a machine executable deallocation structure adapted to automatically deallocate 
idle objects within the server when the server Is executing as a process, the machine executable deallocation struc- 
ture operating according to selected ones of the machine readable storage structures in the server administrator 
object; 

30 wherein the selected ones of the machine readable storage structures include: 

a first attribute that enables or disables the machine executable deallocation structure; 
a second attribute that establishes a cycle time for the machine executable deallocation structure; and, 
a third attribute that establishes an maximum time interval for which the server can be idle, such that the server 
35 is automatically shutdown by machine executable deallocation structure after a time interval equal to or 

exceeding the maximum time interval; 

and wherein selected ones of the machine executable structures of the server administrator object establish 
selected ones of the first, second, and third attributes. 

40 v.^ 

14. The computer system of claim 1 . wherein: 

the computer system includes a machine executable logging structure adapted to log Information regarding 
the execution of the server, the machine executable logging structure operating according to selected ones of the 
machine readable storage structures in the server administrator object; 
45 wherein the selected ones of the machine readable storage structures include: 

a first attribute that enables or disables logging by an operating system process; and 

a second attribute that Identifies at least one log file used by the machine executable logging structure to store 

information, and that establishes a maximum file size for the log file; 

50 

and wherein selected ones of the machine executable structures of the server administrator object establish 
selected ones of the first, and second attributes. 

15. The computer system of claim 1 . wherein selected ones of the machine readable storage structures of the server 
55 administrator object further include: 

a structure adapted to store a heart beat interval value indicative of a frequency for the server to send a signal 
to the server administrator to indicate that the server is currently executing; and. 
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a structure adapted to store a maximum value indicative of a maximum number of signals that the server 
administrator may not receive prior to initiating a process to determine whether the server is currently execut- 
ing. 

1 6. The computer system of claim 1 . wherein: 

the server further includes at least one tracing facility: 

the computer system further includes a machine executable tracing structure adapted to output conditional 
information according to at least one tracing facility in the server; and 

selected ones of the machine executable structures of the server administrator object further comprise: 

a structure adapted to define a tracing configuration including a tracing fadlrty and a set of trace flags, and a 
structure adapted to store the tracing configuration; and. 

a structure adapted to update the tracing facilities in the server with tracing facilities stored in the server admin- 
istrator 

1 7. The computer system of claim 16, wherein selected ones of the machine executable structures include: 

a structure that enables at least one trace flag in a specified tracing facility; and. 
a structure that disables at least one trace flag in a specified tracing facility. 

18. The computer system of claim 1 , wherein selected ones of the machine executable structures include: 

a structure adapted to store an identification of each object interface provided by the server; and. 

a structure adapted to store an identification of each object implementation in the server that implements a 

object interface- 

19. A method for determining and manipulating current configuration information for a server on a host corrputer, the 
method comprising the steps of: 

creating an instance of a persistent first object in a host computer; 

associating the first object with the server during installation of the server, the first object having access to cur- 
rent configuration information of the server; 

receiving by the first object a request from a client for current configuration information about the server; and 
returning to the client current configuration information without invoking the server when the server is not exe- 
cuting as a process on the host computer. 

20. The method of claim 19, further comprising the step of: 

storing in the first object current configuration information upon registration of the server; and 

updating selected stored current configuration information each time the server is executed as a process on 

the host computer. 

21. The method of claim 19, further comprising the steps of: 

receiving by the first object a request from a client for current process information about the server; and 
invoking from the first object a second object internal to server to obtain the process information. . 

22. The method of claim 19, wherein the first object is a server administrator object. 

23. The method of claim 19, further comprising the steps of: 

determining an execution definition for the server; and. 
storing the execution definition in the first object. 

24. The method of claim 23. wherein the execution definition includes a program definition, the method further compris- 
ing the steps of: 

storing a saved program definition for the server in the first object; 
altering the execution definition to provide a new program definition, and. 
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restoring the saved program definition into the execution definition. 

25. The method of claim 23. further comprising the steps of: 

storing a hold down value in the execution definition; and 

suppressing execution of the server according to the hold down value when the server is invoked by a client. 

26. The method of claim 19, further comprising the steps of: 

invoking a pseudo object to determine if the server is currently executing as a process: 
returning a process identifier if the server Is executing; and. 
storing a value indicating that the server is executing. 

27. The method of claim 19. further comprising the steps of: 

storing a program definition for an executable application in an execution definition of the server in the first 
object; and 

interposing the executable application according to the program definition when the server is invoked by a cli- 
ent. 

28. The method of claim 1 9, further comprising the steps of: 

storing in the first object an attribute for enabling or disabling a process for automatically deallocating idle 
objects within the server; 

storing in the first object an attribute for establishing a cycle time for the process; 

storing in the first object an attribute for establishing a maximum time interval for which the server can be idle 
before the server is shutdown by the process; and 

shutting down the server when the maximum time interval is equalled or exceeded. 

29. The method of claim 19. further comprising the steps of: 

storing in the first object an attribute for enabling or disabling logging by an operating system process; 
storing in the first object an attribute for identifying at least one log file for storing information; and, 
storing in the first object an attribute for establishing a maximum file size for the log file. 

30. The method of claim 19, further comprising the steps of: 

storing in the first object a heart beat interval value indicative of a frequency for the server to send a signal to 
the first object to indicate that the server is currently executing; 

storing in the first object a maximum value indicative of a maximum number of signals ^hat the first object may 
not receive prior to initiating a process to determine whether the server is currently executing; and 
initiating a process from the first object to determine whether the server is currently executing if the first object 
does not receive a number of signals equal to or exceeding the maximum number of signals. 

31. The method of claim 19. further comprising the steps of: 

determining a tracing configuration including at least one tracing facility and a set of trace flags in the server; 
storing in the first object the tracing configuration; and 

periodically updating the tracing facilities in the server with tracing facilities stored in the first object. 

32. The method of claim 31 , further comprising the step of: 

selectively enabling at least one trace flag in a specified tracing facility in the first object. 

33. The method of claim 19, further comprising the steps of: 

storing in the first object an identification of each object interface provided by the server; and, 

storing in the first object an identification of each object implementation in the server that implements a object 

interface. 
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